Fix schema sidecar atomic write#9
Conversation
| return sidecarPath, nil | ||
| } | ||
|
|
||
| func writeFileAtomic(path string, content []byte, perm os.FileMode) error { |
There was a problem hiding this comment.
writeFileAtomic gives atomic visibility — readers see either the old file or the fully-written one — but not durability: without tmpFile.Sync() before Close() (and ideally an fsync of the parent dir after Rename), a crash right after Rename can leave the sidecar empty or missing even though the call returned success. For a co-located, startup-regenerated sidecar this is likely fine — just confirming durability isn't a requirement here. If it is, add the syncs.
There was a problem hiding this comment.
Confirmed: this sidecar is regenerated before the function starts, so the requirement is atomic visibility rather than crash durability. I left the sync behavior unchanged.
| }() | ||
|
|
||
| _, writeErr := tmpFile.Write(content) | ||
| chmodErr := tmpFile.Chmod(perm) |
There was a problem hiding this comment.
Minor behavior change worth flagging: os.CreateTemp + Chmod(perm) yields mode 0644 deterministically, whereas the old os.WriteFile(path, content, 0644) produced 0644 &^ umask for a new file and preserved the existing file's mode when the sidecar already existed. The deterministic 0644 is arguably better — flagging only in case a restrictive umask was being relied on.
There was a problem hiding this comment.
Updated the atomic writer to preserve the mode of an existing regular sidecar and to let the process umask set the initial mode for a new one. Added a regression test for existing-mode preservation.
2 participants
Summary
Testing